REMARKS 



The Office Action dated September 26, 2005, has been received and carefully 
noted. The above amendments to the claims, and the following remarks, are submitted as 
a full and complete response thereto. 

Claims 1-15 are currently pending in the application, of which claims 1 , 14, and 
15 are independent claims. Claims 1, 2, 5, 9, 10, 14, and 15 have been amended to more 
particularly point out and distinctly claim the invention. No new matter has been added, 
and no change in scope has been created that would require additional consideration 
and/or search. Claims 1-15 are respectfully submitted for consideration. 

Rejections under 35 U.S.C. 112, second paragraph 

Claims 1, 2, 5, 9, 10, 14, and 15 were rejected under 35 U.S.C. 112, second 
paragraph, as being indefinite because they used the term "such as." As MPEP 
2173.05(d) points out, there is not a per se rule against the term "such as." Moreover, in 
the present application the term was not being used in the illustrative manner that the 
MPEP finds objectionable, but rather a definite way. Nevertheless, to expedite 
prosecution, the term "such as" has been replaced by an equivalent in each of claims 1, 2, 
5, 9, 10, 14, and 15. Accordingly, it is respectfully submitted that the rejection is moot. 
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Rejections under 35 U.S.C. 103(a) 

Claims 1-12 3 14 and 15 were rejected under 35 U.S.C. 103(a) as being 
unpatentable over U.S. Patent No. 6,804,506 of Freitag et al. ("Freitag") in view of U.S. 
Patent No. 6,731,932 of Rune et al. ("Rune"). The Office Action takes the position that 
Freitag teaches all of the elements of the independent claims except "determining 
whether the response is indicative of an error; and if the response is indicative of an error, 
transmitting from the authentication server to the user profile store a message of a type to 
trigger the user profile store to perform a location update procedure in respect of the 
user." The Office Action supplies Rune to remedy the deficiencies of Freitag. 
Applicants respectfully traverse this rejection. 

Claim 1, upon which claims 2-13 depend, is directed to a method for performing 
authentication in a communication system comprising an authentication server (AS), and 
a user profile store storing user profiles for users of the communication system. The 
method includes transmitting from the authentication server to the user profile store a 
request for the user profile of a user, receiving at the AS a response to the request, 
determining whether the response is indicative of an error, and, if the response is 
indicative of an error, transmitting from the authentication server to the user profile store 
a message of a type that triggers the user profile store to perform a location update 
procedure in respect of the user. 

Claim 14 is directed to an authentication server (AS) for performing authentication 
in a communication system comprising a user profile store storing user profiles for users 
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of the communication system, the authentication server being arranged to, in order to 
perform authentication: transmit from the authentication server to the user profile store a 
request for the user profile of a user, receive at the AS a response to the request, 
determine whether the response is indicative of an error, and, if the response is indicative 
of an error, transmit from the authentication server to the user profile store a message of a 
type that triggers the user profile store to perform a location update procedure in respect 
of the user. 

Claim 15 is directed to a communication system including a user profile store 
storing user profiles for users of the communication system, and an authentication server 
(AS) for performing authentication in the communication system and being arranged to, 
in order to perform authentication: transmit from the authentication server to the user 
profile store a request for the user profile of a user, receive at the AS a response to the 
request, determine whether the response is indicative of an error, and if the response is 
indicative of an error, transmit from the authentication server to the user profile store a 
message of a type that triggers the user profile store to perform a location update 
procedure in respect of the user. 

Thus, certain embodiments of the present invention are concerned with 
authenticating a user by obtaining a user profile from a home location register (HLR) in 
circumstances in which the HLR would not normally return the user profile in question in 
response to a user profile request. This can happen, for example, when the user has not 
communicated with network for some time, so that the HLR has deleted the visitor 
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location register (VLR) entry for that user from its database. In such situations, many 
HLRs return an error message in response to a request for the profile of that user. Certain 
embodiments of the present invention address that problem by requesting that the HLR 
perform a location update procedure, by means of which the authentication server obtains 
the user profile from the HLR. 

Certain embodiments of the present invention are particularly applicable to 
authenticating terminals that can access two different networks. For example, when a 
subscriber tries to access a wireless local area network (WLAN) the entity that controls 
the WLAN may conveniently authenticate the subscriber's identity by means of an 
authentication server in a Global System for Mobile communications (GSM) network. 
The authentication server authenticates the subscriber by obtaining the subscriber's user 
profile from the HLR of the GSM network. However, a problem arises if the subscriber 
has not been in communication with the GSM network for some time. In such a case, the 
HLR will have deleted the VLR entry for that subscriber from its database. The HLR 
may therefore return an error message in response to the request for the subscriber's user 
profile. As described above, certain embodiments of the present invention address this 
problem by requesting that the HLR perform a location update procedure. 

It is respectfully submitted that the cited art of Freitag and Rune, whether taken 
singly or in combination, fails to disclose or suggest all of the elements of any of the 
presently pending claims. Therefore, the cited art cannot provide the critical and 
unobvious advantages described above. 
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Freitag is directed to a method, mobile station, and radio communication system 
for controlling safety related functions in communication handling. More particularly, 
Freitag is directed to a method for controlling sercurity-related call functions. As 
disclosed at col. 4 5 11. 33-62 of Freitag, if a VLR does not have the required subscriber 
data when a connection is set up between the VLR and a subscriber terminal, it requests 
the relevant subscriber and security data from the HLR, which retrieves the requested 
security parameters from an authentication center. 

As the Office Action acknowledges at p. 3, 11. 6-10, Frietag does not disclose or 
suggest the steps of "determining whether the response is indicative of an error; and if the 
response is indicative of an error, transmitting from the authentication server to the user 
profile store a message of a type to trigger the user profile store to perform a location 
update procedure in respect of the user." However, as noted above, the Office Action 
asserts that Rune teaches these features. 

Rune generally relates to methods and systems for handling subscriber data. 
Subsciber data in Rune's "Super-charged" network is handled in a network including a 
home network entity containing information regarding subscriber in the network and one 
or more visitor network entities containing subscribers to other networks. A subscriber 
profile in the visitor network entity may be updated if necessary, and if certain conditions 
are met. Depending on the amount of elapsed time since the contact of the subscriber and 
the network, the subscriber's identity may be unallocated, the subscriber's record may be 
purged, and an indication of the purging may be recorded in the home network entity. 
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Rune, therefore, discloses a method of updating and modifying subscriber profile 
information. Rune does not disclose a method for performing authentication in a 
communication system, which appears to have been appreciated by the Office Action, as 
the Office Action combines Rune with Freitag to get the authentication features of 
Freitag. 

Rune, however, does not disclose "determining] whether the response is 
indicative of an error; and if the response is indicative of an error, transmitting from the 
authentication server to the user profile store a message of a type to trigger the user 
profile store to perform a location update procedure in respect of the user." 

Although Rune may disclose determining whether the response is indicative of an 
error, this response is received in response to a request for a user profile transmitted by 
the current VLR to the previous VLR. Rune may disclose transmitting a message to 
trigger a location update procedure in respect of the user to a user profile store if the 
response is indicative of an error. However, this message is not transmitted to the VLR 
from which the response indicative of an error was received. Instead, this message is 
transmitted to the HLR, as explained at col 1 1, 11. 23-47 of Rune. Therefore, the method 
in Rune differs from the method defined in claims 1, 14, and 15, not only because Rune is 
not concerned with authentication, but also because claims 1, 14, and 15 define that the 
request for the user profile of a user and the subsequent message for triggering a location 
update procedure are transmitted to the same user profile store. In contrast, Rune 
transmits these messages to different user profile stores (the VLR and HLR respectively). 
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Therefore, Rune does not disclose the steps of "determining] whether the response is 
indicative of an error; and if the response is indicative of an error, transmitting from the 
authentication server to the user profile store a message of a type to trigger the user 
profile store to perform a location update procedure in respect of the user." The result of 
this difference is the accomplishment of the very different objectives of certain 
embodiments of the present invention, as compared with Rune. Accordingly, it would 
not have been obvious to modify Rune to obtain the presently claimed invention. 

In Rune, the user profile is requested from the previous VLR if the HLR 
determines that the previous VLR and the current VLR are located in the same country or 
PLMN, as explained at col. 11, 11. 14-21 of Rune. Therefore, rather than the HLR 
transmitting the user profile to the current VLR itself (as in the systems described in 
Rune as "prior art"), the HLR instructs the current VLR to obtain the user profile from 
the previous VLR so as to avoid the data having to be transmitted internationally. The 
section of Rune referred to by the Office Action deals with the situation in which the user 
profile is not successfully retrieved from the previous VLR. In this situation, the current 
VLR requests the user profile from the HLR as it is unable to obtain the information it 
requires from the previous VLR. However, it is not possible to retrieve the user profile 
from the HLR when the user has not been communicating with the network for some 
time, as in such a scenario, the user profile will not be returned by the HLR either. This 
problem is addressed by certain embodiments of the present invention but is not 
considered by Rune. Rune is concerned with updating and modifying subscriber profile 
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data as a subscriber roams between cells. In other words, Rune is concerned with how to 
ensure user profiles are kept up to date when a subscriber is connected to the network and 
not with authenticating a subscriber who has not been connected to the network for some 
time. Therefore, Rune would not suggest to one of ordinary skill in the art the steps of 
determining and triggering a location update procedure as claimed in claim 1, because 
Rune does not suggest any reason for which a request for the user profile of a user and 
the subsequent message for triggering a location update procedure should be transmitted 
to the same user profile store. 

Additionally, one of ordinary skill in the art would not find it obvious to transmit 
these different messages to the same user data store from the teachings of Rune. Rune 
does not consider that the data is always freely available from the HLR. If the request for 
the user profile is transmitted to the HLR according to the method of Rune, one of 
ordinary skill in the art would not conceive of receiving a response indicative of an error 
from the HLR, as claimed in claim 1. Therefore, one of ordinary skill in the art would 
see no reason to transmit both a request for a user profile and a message of a type to 
trigger a location update procedure in respect of the user the HLR. Similarly, although 
Rune does consider that a VLR might not be able to provide a user profile in response to 
a request, Rune would not suggest transmitting a message for triggering a location update 
procedure to the VLR. This is because location updates are performed by the HLR and 
not the VLR, so one of ordinary skill in the art would not find it obvious to transmit a 
message to trigger a location update to a VLR. Therefore, Rune would not suggest to one 
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of ordinary skill in the art the steps of determining and triggering a location update 
procedure as claimed in claim 1, because it is not obvious from Rune to transmit a 
request for the user profile of a user and the subsequent message for triggering a location 
update procedure to the same user profile store. 

Even if Rune were to disclose transmitting the request for the user profile of a user 
and a message for triggering a location update procedure to the same user profile store 
(not admitted), one of ordinary skill in the art would still not find it obvious to combine 
Rune and Freitag in such a way as to obtain the features of claim 1. The Office Action 
asserts that because both Rune and Freitag are directed towards methods for handling 
subscriber data, it would have been obvious to one of ordinary skill in the art to combine 
them. However, the Office Action does not provide any basis for which the skilled 
person would have combined them and has, thus, failed to establish that one of ordinary 
skill in the art would have had any motivation, teaching, or suggestion to do so. 

Furthermore, even one of ordinary skill in the art had combined the documents as 
the Office Action proposes, a method of performing authentication of a user in which an 
authentication server transmits a message to a user profile store of a type such as to 
trigger a location update procedure in respect of the user obvious from the combination 
would not have been the result. Location update procedures are triggered to update the 
location of the terminal as it roams between cells (as is apparent from Rune). Therefore, 
messages to trigger location update procedures in a user data store are conventionally 
transmitted by the VLRs so that the HLR can update the subscriber's location 
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information. If an authentication server rather than a VLR were to trigger a location 
update procedure (as claimed in claim 1), this would be expected (by one of ordinary skill 
in the art, without the benefit of Applicants' disclosure) to cause problems for the 
subscriber's connection in the network (as explained in the final paragraph of page 8 of 
the application). This problem is avoided in the method of claim 1 because the subscriber 
is not connected to the network when the user profile is requested from the user data 
store. However, as neither Rune nor Freitag disclose methods in which the subscriber is 
not connected to the network, this would not be obvious to one of ordinary skill in the art. 
Therefore, one of ordinary skill in the art would not find a method of authenticating a 
user in which an authentication server transmits a message to a user profile store of a type 
so as to trigger a location update procedure in respect of the user obvious from a 
combination of Rune and Freitag. 

Therefore, the combination of Rune and Freitag do not teach or suggest all of the 
elements of the claimed invention, and it would not have been obvious to combine them 
to obtain the claimed invention. Thus, it is respectfully requested that this rejection be 
withdrawn. 

Claims 2-12 depend from claim 1 and recite additional limitations. Accordingly, it 
is respectfully submitted that Rune and Freitag do not disclose or suggest all of the 
limitations of any of dependent claims 2-12. 

Claim 13 was rejected under 35 U.S.C. 103(a) as being unpatentable over Freitag 
in view of Rune and further in view of U.S. Patent Application No. 2003/0051041 of 
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Claim 13 was rejected under 35 U.S.C. 103(a) as being unpatentable over Freitag 
in view of Rune and further in view of U.S. Patent Application No. 2003/0051041 of 
Kalavade et al. ("Kalavade"). The Office Action takes the position that Freitag and Rune 
teach all of the elements of claim 13 except "wherein the network other than the one of 
which the user profile store is a part. Applicants respectfully traverse this rejection. 

Freitag and Rune are discussed above. Kalavade is directed to a method and 
apparatus for integrating billing and authentication functions in local area and wide area 
wireless data networks. Kalavade generally describes a converged network accessible by 
client networks, in which a gateway integrates billing and authentication functions of the 
wide area and local area networks. 

Claim 13 depends from claim 1. As explained above Freitag and Rune fail to 
disclose or suggest all of the elements of claim 1. Kalavade fails to remedy the 
deficiencies of Freitag and Rune, because Kalavade is silent with regard to the elements 
that Freitag and Rune fail to disclose, namely, "determining] whether the response is 
indicative of an error; and if the response is indicative of an error, transmitting from the 
authentication server to the user profile store a message of a type to trigger the user 
profile store to perform a location update procedure in respect of the user." Accordingly, 
it is respectfully requested that this rejection be withdrawn. 
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Conclusion 

For the reasons explained above, it is respectfully submitted that each of claims 
1-15 recites subject matter that is neither disclosed nor suggested in the cited art. 
Accordingly, it is respectfully requested that all of claims 1-15 be allowed, and that the 
application be passed to issue. 

If for any reason the Examiner determines that the application is not now in 
condition for allowance, it is respectfully requested that the Examiner contact, by 
telephone, the applicants' undersigned attorney at the indicated telephone number to 
rrange for an interview to expedite the disposition of this application. 
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In the event this paper is not being timely filed, the applicants respectfully petition 
for an appropriate extension of time. Any fees for such an extension together with any 
additional fees may be charged to Counsel's Deposit Account 50-2222. 



Customer No. 32294 

SQUIRE, SANDERS & DEMPSEY LLP 
14 th Floor 

8000 Towers Crescent Drive 
Tysons Corner, Virginia 22182-2700 
Telephone: 703-720-7800 
Fax: 703-720-7802 

DHG:kmp 

Enclosures : Petition for a One-Month Extension of Time ( 1 ) 



Respectfully submitted, 




Check No. 13894 
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